Extend DCP initialization timeout through API readiness - #19641
Extend DCP initialization timeout through API readiness#19641Adam Ratzman (adamint) wants to merge 1 commit into
Conversation
Keep the initialization retry budget until an eager DCP API call succeeds, then use the normal steady-state budget. Propagate timeout cancellation into the Kubernetes client calls and cover both transitions. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2faf8d87-e20d-4c7c-95cf-07abd6179e13
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19641Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19641" |
github-actions
Bot
added
the
needs-area-label
There was a problem hiding this comment.
Pull request overview
Extends DCP initialization handling until the first successful API operation.
Changes:
- Propagates Polly cancellation tokens to Kubernetes requests.
- Tracks API readiness and adds timeout regression tests.
Show a summary per file
| File | Description |
|---|---|
src/Aspire.Hosting/Dcp/KubernetesService.cs |
Extends startup retry handling through API readiness. |
tests/Aspire.Hosting.Tests/Dcp/KubernetesServiceTests.cs |
Tests readiness, steady-state timeout, and cancellation. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Balanced
Tests selector (audit mode)The full test matrix and all jobs still run in audit mode. The tests and jobs below are what selective CI would run under enforcement. 50 / 102 test projects · 4 jobs, from 2 changed files. Selected test projects (50 / 102)
Selected jobs (4)
How these were chosen — grouped by what changed
🔧 show 45
🧪 📦 affected project Job reasons
Selection computed for commit |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
Description
#19636 gave initial DCP kubeconfig discovery and client creation a separate 60-second timeout, but its first CI run still timed out in the first DCP API operation after the client was initialized. A parsed kubeconfig does not mean DCP is ready to process requests yet.
This keeps the startup timeout through the first successful eager DCP API operation. Calls that start before readiness retain that startup budget; later calls use the existing 20-second retry budget. Lazy watches do not publish readiness, and Polly's timeout token now reaches the underlying Kubernetes requests so stalled requests are canceled.
The regression coverage now checks delayed kubeconfig creation, delayed first API success, the transition back to the steady-state timeout, and cancellation of a stalled HTTP request.
Follow-up to #19636.
Checklist
<remarks />and<code />elements on your triple slash comments?